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(54) Multiple operating system control method 

(57) An inter-OS control software for switching OS's 
in operation executed on a single CPU is installed, and 
plural OS's are made alternately executed. A control 
program is executed exclusively on one OS, which con- 
trols the controlled apparatus. A supervisory control pro- 



gram and a development environment program are ex- 
ecuted on another OS, and a memory space is divided 
so as to make no effect for the operation of the control 
program. A higher real-time performance and reliability 
can be established with a single CPU architecture. 
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Descriptl n 

[0001] The present invention relates to a control 
method of the control apparatus using a digital arithme- 
tic processor for plant instrument control and/or various 5 
machine control, and specifically, to a control method 
for the multiple operating system in which plural operat- 
ing systems are executed on an single processor. 
[0002] In the* control apparatus such as programma- 
ble logic controller (PLC) or numerical control apparatus 
(CNC) often used for plant instrument control and vari- 
ous machine controls, procedures for control logic are 
executed mainly. The functions other than procedures 
for control logic including the function for inputting the 
control logic into those control apparatus (development 
environment) and the functions for supervisory opera- 
tion for the controlled status and for allowing the user to 
input the data in an interactive manner (human machine 
interface) are often realized by another apparatus such 
as personal computers (PC's) connected outside the 
control apparatus (hereinafter referred to as user inter- 
face apparatus.) In case that those functions are em- 
bedded in a single apparatus, those functions are exe- 
cuted by the individual internal arithmetic processors. A 
technology related to this kind of apparatus is disclosed, 
for example, in Japanese Patent Application Laid-Open 
Number 9-62324 (1997). 

[0003] The performance of PC's used as a user inter- 
face apparatus has increased, and thus, computational 
power can be provided so that a single PC may cover 
the functions from the control logic operations to the de- 
velopment environment and the supervisory control up 
to a certain scale of control systems. However, in case 
of using a control apparatus comprising a PC-based 
hardware architecture supporting all of the system func- 
tions and applying an operating system (OS) generally 
used in PC's, the operations of the programs and the 
device drivers other than the control programs may af- 
fect the operation of the control programs themselves. 
[0004] There is such a technology that computer re- 
sources are shared in common with multiple OS's and 
the functions generic to the individual OS's are used by 
loading and running plural OS's on an single CPU. Ex- 
amples of this technology are disclosed in Japanese 
Patent Application Laid-Open Number 5-73340 (1993), 45 
Japanese Patent Application Laid-Open Number 
5-27954 (1993) and Japanese Patent Application Laid- 
Open Number 5-151003 (1993). 

[0005] Privileged instructions are executed generally 
in OS's. Therefore, some disability occurring in one of so 
OS's may affects the execution of the other OS's. How- 
ever, this affect is not considered in the technology in 
which plural OS's are loaded and ran simultaneously on 
a single computer, and hence, even by means of isolat- 
ing the influence of the disabled OS over the other OS's 55 
by emulating the disabled OS by the other OS's as de- 
scribed in and Japanese Patent Application Laid-Open 
Number 5-1510003 (1993), the influence may be prop- 



agated onto the operations of both OS's in cas that 
some disability may occur the OS emulating the disa- 
bled OS. 

[0006] Preferably, in the present invention, in order to 
solve the above problems, a software for controlling 
OS's is loaded in order to switch the executing OS's so 
that plural OS's may be operated alternately. The control 
software is made executed on the OS with higher relia- 
bility, and the user interface program is made executed 
on the OS with rich functionality, and thus, OS's each 
having specific characteristics are made executed on a 
single CPU. In responsive to the generation of interrupt 
or the request signal from OS's or the software programs 
running on OS's, this inter-OS control software stores 
and revises the context information of CPU operations 
(for example, register values of CPU), switches the 
memory spaces and restarts the OS operations in an- 
other context stored in past. In other words , the opera- 
tion of the running OS is terminated and the operation 
of other OS's is restarted. In addition, the inter-OS con- 
trol software has a function which monitors start-stop 
operations of the running OS'S and controls the start- 
stop operation of the individual OS's independently. Ow- 
ing to this configuration, it will be appreciate that the 
hardware and software in the control apparatus can be 
partially initialized and that the disabled part can be au- 
tomatically recovered, which leads to higher reliability of 
the total system. 

[0007] Preferably, individual memory spaces occu- 
pied for the individual OS's and a memory space shared 
and accessible commonly by plural OS's are defined on 
the physical memory. Owing to this configuration, the 
individual memory spaces for the kernel and the pro- 
grams are so defined that the interference among OS's 
such as data destruction may be avoided and that the 
necessary data may be shared by the programs each 
executed on the difference OS's. In addition, the system 
has such a function that the program running on a c r- 
tain OS waits for the event issued by the other OS's and/ 
or the programs running on those OS's and the inter-OS 
control software notifies this event. Owing to this con- 
figuration, a communication function between the pro- 
grams running on the different OS's can be established. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0008] 

FIG. 1 is a block diagram of the embodiment using 
the present invention. 

FIG. 2 is a schematic diagram of memory usage in 
the control apparatus. 

FIG. 3 is a flowchart showing procedures for the in- 
terrupt operation in the execution of OS-A. 
FIG. 4 is a flowchart showing procedures for the in- 
terrupt operation in the execution of OS-B. 
FIG. 5 is a flowchart showing procedures for the 
switching operation of OS's. 
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FIG. 6 is a schematic diagram showing a function 
for issuing and notifying events. 
FIG. 7 is a flowchart showing procedures for restart- 
ing OS-A exclusively. 

PREFERRED EMBODIMENTS OF THE INVENTION 

[0009] 'FIG. "1 shows a bock diagramof "the control ap- 
paratus in one embodiment of the present invention. 
[0010] The hardware for the control apparatus 1 com- 
prises a central processing unit (CPU) 11, a physical 
memory 12, a timer 14, a user input output apparatus 
16, a network interface apparatus 18 and a interrupt 
controller 19. This structure is the same as the structure 
in a general purpose personal computer (PC). The con- 
trol apparatus 1 has a network interface apparatus 18 
connected to the network s, and uses it for communi- 
cating with another control apparatus and reporting the 
control result to the host computer. The control appara- 
tus has an input and output apparatus connected to the 
controlled apparatus 2 for exchanging signals, and ac- 
quires the information from the controlled apparatus 2 
and issues the operation instruction to the controlled ap- 
paratus 2. The interrupt controller 19 of the control ap- 
paratus 1 relays the interrupt signal from the individual 
components of the control apparatus 1 to CPU 11 and/ 
or masks the interrupt signal. 

[0011] The software of the control comprises an op- 
erating system A (OS-A) 21 and an operating system B 
(OS-B) both for the hardware resource management 
and the executive control of the program running on it, 
an inter-OS control software 23 for switching OS-A and 
OS-B, a supervisory control program 2 and a develop- 
ment environment program 25 both executed on OS-A, 
and a control program 26 executed on OS-B. OS-A, OS- 
B and the inter-OS control software 23 are operated on 
an single CPU 11 in a privileged mode and enabled to 
execute all the instructions including the privileged in- 
structions for controlling CPU 11 itself. On the other 
hand, the programs running on the individual OS's are 
operated in a non-privileged mode and can not execute 
privileged instructions. OS-A and OS-B contains device 
drivers operating in a privileged mode as well as the OS 
kernel, and in the following, those devices are discussed 
so as to be unified in the OS kernel. 
[0012] The input and output apparatus 12 is controlled 
and occupied by OS-B. On the other hand, the user input 
and output apparatus and the network interface appa- 
ratus 18 used by the programs operated on OS-A are 
controlled and occupied by OS-A. Such a configuration 
is allowed that such a exigency user input and output 
apparatus as emergency stop button and alarm signal 
output and/or such a network interface apparatus as re- 
quiring real-time characteristics for communicating with 
another control apparatus may be controlled and occu- 
pied by OS-B and accessed by the programs running 
on OS-B. The physical memory 13 ar separated into 
the area 131 for OS-A and the area 132 for OS-B. The 



hard wares accessed directly by the inter-OS control 
software 23 are limited to the timer 14 and the interrupt 
controller 19. 

[0013] At first, the overall operation of the software 
5 and its relation to the hardware are described. In this 
embodiment, OS-A is assumed to be a general purpose 
OS commonly used in PC's. OS-A provides sophisticat- 
ed user interfaces for the supervisory control program 
24 and the development environment program 25. OS- 
10 a and the programs running on OS-A operate in the sim- 
ilar manner to the case that OS-B does not exist. Though 
the inter-OS control software 23 interrupts the operation 
of OS-A, and OS-B is switched over OS-A, as the inter- 
OS control software 23 recovers the interrupted opera- 
15 tion of OS-A and restarts OS-A after completing the op- 
eration of OS-B, it is not necessary for OS-A to recog- 
nize the existence of OS-B. 

[0014] On the other hand, OS-B is assumed to be one 
that is characterized as higher real-time performance 

20 and optimized for control programs. OS-B yields its ex- 
ecutive status to OS-A when the programs running on 
OS-B have no more operations to be executed (herein- 
after referred to as "idle status".) 
[0015] The inter-OS control software 23 provides 

25 functions for switching the execution status between 
OS-A and OS-B, and for communicating among pro- 
grams on OS's. The switching operation of the execution 
status from OS-A to OS-B is performed in case that i) 
an interrupt occurs at the hardware controlled by OS-B, 

30 jj) a pre-defined period of time has passed or iii) OS-A 
communicates to OS-B. The switching operation of the 
execution status from OS-B to OS-A is performed only 
when OS-B turns into an idle status as described above. 
OS-B has always a execution status in preference to 

35 OS-A owing to this switching operation. The inter-OS 
control software 23 operates only when the switching 
operation is initiated and the communication between 
OS's are requested, and the individual OS's are operat- 
ed independently otherwise. The privileged instructions 

40 to CPU 1 1 are issued by the individual OS's, but are not 
emulated by the inter-OS control software 23. It is re- 
quired that the inter-OS control software 23 may oper- 
ates as a part of the individual OS's so as to enable to 
execute privileged mode instructions every time when 

45 either of OS's is executed. In particular, the inter-OS 
control software 23 is so embedded as to operates as 
a device driver for OS-A when OS-A is executed as a 
general purpose OS. 

[0016] As described above, hard wares are so as- 
50 signed to OS-A and OS-B as to be occupied and con- 
trolled by the individual OS's, and the operation status 
of OS's are switched alternately, and the individual OS's 
are executed independently after the switching opera- 
tion. The inter-OS control software 23 switches the ex- 
55 ecution of both OS's and provides the communication 
function between both OS's. 

[0017] Next, a method for establishing the independ- 
ency between OS's is d scribed. At first, a method for 
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protecting the hard wares controlled and supervised by 
the individual OS from interference by another OS's. 
The interaction between individual hard wares and soft- 
ware includes the input and output operation for the I/O 
addresses assigned to the individual hard wares and the 
response operation of the software to the interrupts with 
their interrupt numbers each assigned to the individual 
hard ware. Thus, the independency between OS's with 
respect to the hard ware controf is established by en- 
suring that the input and output operation to the I/O ad- 
dresses assigned to the hardware controlled and man- 
aged exclusively by one OS and the response operation 
to the interrupt number assigned to this hardware may 
not be executed by the other OS. 
[0018] In order to specify which OS should manage 
and occupy the individual hardware, the I/O address and 
the interrupt number assigned to the hardware are uni- 
fied and stored in the interrupt table in the inter-OS con- 
trol software 23. The inter-OS control software 23 initial- 
ize the device driver of OS-A at the start-up of the control 
apparatus 1 . In its initialization process, the I/O address 
and the interrupt number of the hardware for OSB are 
reserved and made registered in the interrupt table. By 
this process, the kernel of OS-A and the other device 
drivers of OS-A recognize that the corresponding I/O ad- 
dress and interrupt number are occupied, and then, the 
operation to those hard wares by OS-A is disabled. On 
the other hand, by means that the I/O address and the 
interrupt number of the hardware occupied by OS-A are 
made acquired by OS-B directly from the inter-OS con- 
trol software 23 and registered in the interrupt table, the 
operation to those hard wares by OS-B is made disa- 
bled. According to the above procedures, the independ- 
ency between OS's with respect to the hard ware control 
is established. 

[001 9] The input and output operation to the hardware 
is executed by OS-A and OS-B, respectively, and is not 
emulated by the inter-OS control software 23. Owing to 
this procedure, the additional overhead due to the em- 
ulation of the input and output operation can be prevent- 
ed as well as the kernel and device drivers assumed to 
access directly to the hardware may not be modified. 
[0020] Nest, a method for establishing the independ- 
ency of the physical memory space used by the individ- 
ual OS's is described. The independency of the physical 
memory 1 3 is established by defining the memory areas 
used separately for OS-A and OS-B, respectively The 
memory area used commonly with OS-A and OS-B is 
defined for sharing the data between both OS's. 
[0021] In order to define the separated areas individ- 
ually occupied by OS-A or OS-B, at first, OS-A is made 
started when the control apparatus 1 starts up, and then, 
the memory areas are so defined that the physical mem- 
ory area lower than the designated address specified by 
the start-up option of OS-A may be occupied by OS-A. 
After start-up of OS-A, OS-B is made start d by loading 
OS-B onto the physical memory area higher than the 
designated address. The kernel of OS-B acquires the 



designated address recorded on the table in the inter- 
OS control software 23, and uses the area which is not 
used by OS-B under the memory manag ment. 
[0022] There are two cases for the memory area com* 
5 monly shared by OS's. In one case, the memory area 
for the OS-A is made mapped on the address space for 
OS-B. In this case, the inter-OS control software 23 re- 
quests the memory management mecnanism or the ker- 
nel of OS-B to add the address of the physical memory 

w to be shared to the logical address conversion table 
(hereinafter referred to as "page table") for the physical 
memory for OS-B and to make the physical memory cor- 
respond to the logical address (hereinafter referred to 
as "memory mapping" or simply to "mapping".) In the 

is other case, the memory area for OS- is made mapped 
on the address space for OS-A. In this case, the inter- 
OS control software 23 reserves the address of the 
physical memory to be shared as a device driver of OS- 
A. In this case, a function of OS-A for realizing the device 

20 driver of the memory-mapping type physical device is 
used. Owing to this configuration, the kernel of OS-A 
maps the physical memory to be shared onto the page 
table for OS-A, which establishes the sharing of the des- 
ignated common memory area. 

25 [0023] Next, a method for establishing the independ- 
ency of the logical address spaces of the individual OS's 
is described. OS and the programs executed on it ac- 
cess to the memories with reference to logical address- 
es, and the conversion from logical addresses to phys- 

30 ical addresses are automated by CPU referring to the 
page table. The individual memory management func- 
tions embedded in OS-A and OS-B operates the page 
table and perform the mapping operation. At this time, 
by means that the page table is made separated into 

35 tables each used exclusively by the individual OS and 
switched in responsive to the OS's operation privilege, 
the mapping operation can be executed independently 
by the individual OS. 

[0024] The page table is a table located on the phys- 
40 ical memory, and CPU has a register specifying the start 
physical address of the table. CPU obtains the address 
position of the page table from this register, and auto- 
mates the address conversion in responsive to the ob- 
tained information. Therefore, the individual page table 
45 areas for OS-A and OS-B are defined independently on 
the physical memories, and the content of the register 
specifying the page table position is made switched so 
as to specify the page table for OS switched to be ena- 
bled in the OS switching operation by the inter-OS con- 
50 trol software 23. Owing to this procedure, both OS's can 
operates the mapping on the individual page tables, and 
thus, the independency of the logical address spaces 
can be established. 

[0025] The memory usage scheme described above 
55 for the physical memory space and the logical address 
space is shown in FIG. 2. The physical memory space 
51 is made delimited into several areas including an ar- 
ea 52 for the kernel of OS-A, an area 54 for the OS-A 
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programs, an area 56forthe kernel of OS-B and an area 
57 for OS-B programs, which are made enabled to be 
accessed by the individual resources assigned to OS-A 
and OS-B. The logical address spaces 61 and 62 for the 
memories recognized by OS-A and OS-B are independ- 5 
ent logical address spaces corresponding to the inde- 
pendent page tables of the individual OS's. When OS- 
A is executed, the physical memory spaces 56 and 57 
occupied for OS-B are not mapped onto the logical ad- 
dress space 61 . Owing to this configuration, the areas 10 
for OS-B are not accessed by OS- A with its execution 
enabled, which leads to preventing the data from being 
damaged accidentally. When OS-B is executed, in con- 
trast, the physical memory spaces 52 and 54 occupied 
for OS-A are not mapped onto the logical address space 15 
62. As the inter-OS control software 23 should operates 
in either case of OS's alternate execution, the memory 
area 53 is mapped in either OS and accessible by the 
programs executed on the individual OS's and available 
for exchanging data between programs executed on the 20 
individual OS's. By means that the sharable area for OS- 
A and OS-B is limited to be used for the programs exe- 
cuted in a non-privileged mode, it will be appreciated 
that the kernel and device driver for one OS is made not 
affected by the other OS and its programs, and the in- 25 
dependency and reliability of the individual OS's can be 
established. It is allowed that the individual area may be 
made segmented and distributed for the managed unit 
of the address conversion mechanism of CPU 11 on the 
physical memory area 51 . 30 
[0026] According to the methods described above, 
the dependency of OS's can be established. 
[0027] Next, the operation of the inter-OS control soft- 
ware 23 is described in detail. When the inter-OS control 
software 23 is called explicitly by the individual OS's or. 35 
their programs and an interrupt is applied to CPU, it is 
made started up. As the inter-OS control software 23 is 
embedded as a device driver of OSA, the call by OS-A 
or programs executed on it is realized as an operation 
instruction directed to the corresponding device driver *o 
(for example, IOCTL instruction). As OS-B recognizes 
the existence of the inter-OS control software 23, OS-B 
or programs executed on it are called as a function all 
from the procedure in the kernel of OS-B. As CPU 11 
calls the interrupt handler by referring to the interrupt 45 
table located on the physical memory 13 when an inter- 
rupt occurs, all the interrupt handlers are defined as rou- 
tines in the inter-OS control software 23 by modifying 
the interrupt table. Owing to this configuration, the inter- 
OS control software 23 is activated when any interrupt 50 
occurs, which leads to establishing adequate proce- 
dures. 

[0028] Once the inter-OS control software 23 is made 
start up, it switches OS's in responsive to its causal 
vent, and performs necessary procedures for commu- ss 
nicating betw n OS's. Its procedural st ps are de- 
scribed in detail below. 

[0029] FIG. 3 shows the procedural steps for the case 



that an interrupt occurs while OS-A with its execution 
being defined with nonpriority is in operation. As the re- 
sult of the interrupt input, an interrupt processing routine 
of the inter-OS control software 23 is called, and the pro- 
cedures shown in FIG, 3 are executed. At first, the con- 
tent of the register when the interrupt occurs is trans- 
ferred onto the stack and a stack frame is generated 
(S01 ). Next, by referring to an interrupt number (vector), 
what is judged is whether the interrupt is a software in- 
terrupt or a hardware interrupt (S02). In case of the soft- 
ware interrupt, the cause of the interrupt is either a case 
that an interrupt instruction is issued explicitly by the 
process of OS-A in operation or a case that an exception 
occurs due to its program operation, and in either case, 
the interrupt handler of OS-A itself is called. On the other 
hand, in case of the hardware interrupt, which hardware 
makes the cause of the interrupt is judged (S03). In case 
that the interrupt comes from the hardware managed by 
OS-A, the interrupt handler of OS-A itself is called in the 
similar manner to the software interrupt. In contrast, in 
case that the interrupt comes from the hardware man- 
aged by OS-B, the operation environment is switched 
to OS-B (S04), and then, the interrupt handler of OS-B 
itself is called. In case that the interrupt is a timer inter- 
rupt, the time when the interrupt occurs is identified 
(S05), and if the identified time is a time when the timer 
for OS-A or OS-B should be time up, the timer handler 
of the individual OS itself is called. In case that both tim- 
ers reach the time for the scheduled time-up, the time- 
up of the timer for OS-A is made withheld, and only the 
timer handler of OS-B with its execution given priority is 
called. 

[0030] FIG. 4 shows the procedural steps for the case 
that an interrupt occurs while OS-B with its execution 
being defined with priority is in operation. In this case, 
as in the similar manner to the case that an interrupt 
occurs while OS-A is in operation, as the result of the 
interrupt input, an interrupt processing routine of the in- 
ter-OS control software 23 is called, and the procedures 
shown in FIG. 4 are executed. At first, the content of the 
register when the interrupt occurs is transferred onto the 
stack (S11). Next, by referring to an interrupt number 
(vector), what is judged is whether the interrupt is a soft- 
ware interrupt or a hardware interrupt (S12). In case of 
the software interrupt, the interrupt handler of OS-B in 
operation is called. In case of the hardware interrupt, the 
interrupt controller 19 is made operated when enabling 
OS-B to be in operation, and the interrupt from the hard- 
ware managed by OS-A is masked. Thus, the interrupt 
by the hardware managed by OS-A doe not occur while 
OS-B is in operation. In case that an interrupt occurs at 
the hardware managed by OS-B, the interrupt handler 
of OS-B itself is called in the similar manner to the case 
for the software interrupt. However, in case that the in- 
terrupt is a timer interrupt, the time when the interrupt 
occurs is identified (S14), and if the identified time is a 
time when the tim r for OS-B should be time up, the tim- 
er handler of OS-B itself is called. If the identified time 
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is a time when the timer for OS-A should be time up, the 
fact of the occurrence of the time up is recorded (S15), 
and the opieration of OS-B is recovered. As the system 
has such a hardware configuration that the operation of 
the interrupt controller 19 is not allowed explicitly, the 
cause of the interrupt is judged to be an apparatus man- 
aged by OS-A, the fact of the occurrence of the interrupt 
is recorded when the cause of the interrupt is judged 
(S13), and the interrupt handler of OS-A itself may be 
called when enabling OS-A to be in operation. 
[0031] The above description refers to the operation 
in case that OS-B is made given priority completely. In 
this process, the operation for switching from OS-B to 
OS-A is executed only when OS-B turns into an idle 
state, and a process for notifying the fact of the idle state 
from OS-B to the inter-OS control software 23 is called. 
In view of the avoidance of the deadlock when OS-B 
gets into an infinite loop, an operation of OS-A is sched- 
uled in a definite time fraction. Thus, an timer interrupt 
is made occur at the time other than the time when the 
timers for OS-A and OS-B are count up, and OS's are 
switched in the interrupt process of the inter-OS control 
software 23. In the inter-OS control software 23, the ex- 
ecution time for the individual OS's are estimated before 
hand. If a timer interrupt occurs while OS-B is in opera- 
tion, whether the time for switching from OS-B to OS-A 
has come is judged by referring to the pre-defined exe- 
cution time of OS-B (S16), and then, if the time for 
switching to OS-A has come, OS-A is made enabled to 
be in operation (S17) and the procedure goes to the in- 
terrupt point for OS-A. If the time for switching to OS-A 
has not come, the procedure visits again the interrupt 
point at the time when the interrupt of OS-B occurs. In 
contrast, a timer interrupt occurs while OS-A is in oper- 
ation, in the procedure shown in FIG. 3, whether OS-B 
is staying in an idle state is judged (S06), and then, if 
OS-B is not in an idle state, whether the time has passed 
for going back to OS-B is judged (S07). If the time has 
passed for going back to OS-B, OS-B is made enabled 
to be in operation (S08), and the procedure goes to the 
interrupt point for OS-B. However, if OS-B is staying in 
an idle state or the time has not passed for going back 
to OS-B, then the procedure visits again the interrupt 
point at the when the interrupt of OS-A occurs again. 
[0032] FIG. 5 shows a detail procedure of switching 
OS's in the inter-OS control software 32. The OS switch- 
ing procedure is invoked in case that the switching pro- 
cedure is required in the interrupt process described 
above, that OS-B turns into an idle state or that the 
stand-by state of the stand-by program of OS-B is re- 
quired to be cancelled in responsive to the notification 
of the event which will be described later. At first, the 
context at the point (hereinafter referred to as "interrupt 
point") wh n the interrupt occurs or the inter-OS control 
software 23 is invoked is stored (S31). This means that 
the stack frame position where the content of the regis- 
ter in CPU11 at the interrupt point is recorded and the 
values of the instruction counter and the stack pointer 



are recorded. Next, the property of the interrupt control- 
ler 19 is modified so as to apply a mask for pr venting 
the interrupt of OS-A while OS-B is in operation or to 
cancel a mask for the interrupt of OS-A. 

5 [0033] Next, the register indicating the top memory 
position of the page table is modified and the memory 
space is made switched (S33). This operation is as 
same as described before. Next, the notification of the 
event between OS's is executed (S34), which will be de- 

10 scribed later in detail. When switching from OS-A to OS- 
B, the interrupt routine corresponding to the interrupt 
with its causal event recorded in step S15 of the proce- 
dure shown in FIG. 4 is called and the suspended inter- 
rupt operations are made executed (S35). Then, after 

*s completing all the recorded interrupt operations (S36), 
the context stored in S31 while suspending the interrupt 
operations is recovered (S38), and the procedure visits 
again the interrupt point of the switched OS. All the nec- 
essary data are stored on the memory so that the con- 

20 tent of the register may be deleted when OS-B is ex- 
pected to be switched to OS-A while OS-B is stayinjg in 
an idle state, and the context is made not recovered 
when the interrupt handler of OS-B is called (S37). 
[0034] The interrupt controller 19 can mask the indi- 

25 vidual interrupt operation by specifying its interrupt 
number, and in case that OS-A operates independently, 
the interrupt mask with lower priority is applied while 
processing the interrupt operation of OS-A. in case that 
the masked interrupt include the interrupt of OS-B, a 

30 time day occurs in the corresponding interrupt operation 
until the mask is released.. In order to avoid this time 
delay, it is required to modify the interrupt controller 
process in the kernel of OS-A so that the interrupt oper- 
ation with the interrupt number for OS-B may be made 

35 ; disabled. On the other hand, the timer interrupt of OS- 
A is processed only in a definite time interval in respon- 
sive to the interrupt signal from the timer 14, and thus, 
the timer 14 is not operated while OS-A is in operation, 
but operated once at the initialization process. There- 
to fore, the interrupt signal from the timer 14 is received 
temporarily by the inter-OS control software 23, and it 
is allowed that the interrupt handler of OS-A is only 
called in the steps after S03 of the procedure shown in 
FIG. 3. 

45 [0035] There is such a case that the inter-OS control 
software 23 is called explicitly by either OS for the com- 
munication function between a couple of OS's. A func- 
tion for issuing and notifying events between OS's as a 
basic function for communicating between a couple of 

50 OS's is shown in FIG. 6. 

[0036] There exists an OS-A event processing table 
71 on the memory managed by the inter-OS control soft- 
ware 23. Event numbers, i1, i2, ... iN, are assigned to 
the events enabled to b processed, and there exist 

55 their corresponding N entries. The event table is empty 
at the initial state. After the OS-A program (Program A) 
specifies the event number (i2) and notifies the occur- 
rence of the event and issues the suspend request to 
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the inter-OS control software 23 (S41),the inter-OS con- 
trol program 23 records into the entry i2 of the corre- 
sponding event on the table 71 that the program (Pro- 
gram A) is in a suspended state. The program issuing 
the suspend request stops its operation by the program 
interrupt function of OS-A. Next, if the OS-B program 
(Program B) notifies an event occurrence with its event 
number (iN) (S42), the inter-OS control software 23 
looks up.the corresponding entry iN in the table 71 and 
judges the existence of the program suspended on OS- 
A. In case that there is a suspended program, the re- 
lease request for the suspended program (Program B) 
is issued to OS-A. In responsive to this request, the pro- 
gram suspended on OS-A is restarted and recognized 
that the suspended event is activated. The notification 
of event activation is allowed from the program (Pro- 
gram C) executed on OS-A (S44). Thus, the events is- 
sued on an identical OS and the events issued on the 
different OS's can be made stood by simultaneously. In 
the similar manner, there is an event processing table 
72 for OS-B is defined, and the event to be issued can 
be watched by the program on OS-B in contrast to the 
previous case. 

[0037] The interrupt and restart function of the pro- 
gram used in the event notification described above can 
be realized by a function of OS-A for reporting that the 
inter-OS control software 23 operating as a device driver 
starts and terminates the input and output operation to 
the device. For OS-B, this function can be realized by 
the inter-OS control software 23 calling a routine of OS- 
B for starting and terminating directly the program. 
Though the scope of suspend operation is assumed to 
be on the basis of program in the explanation of the 
event notification in the above description, the interrupt 
and restart operation is applied on the thread-by-thread 
basis in the operating systems providing a multi-thread 
environment. Though the event process table is defined 
so as to contain the program numbers, it is allowed that 
it may contain the structures in OS and their pointers for 
judging the suspended programs in stead. In addition, 
the system is composed with another buffer formed on 
the memory managed by the inter-OS control software 
23, and it is operated so that the data may be received 
from the side of issuing an event and recorded onto the 
buffer at the same time when the event is issued, and 
that the data may be transferred when the suspended 
state is released, and thus, a message communication 
function having a function for waiting the event arrival 
can be realized. 

[0038] The inter-OS control software 23 provides a 
function that allows an continuous operation of either 
one of OS-A or OS-B, and interrupts and restart the oth- 
er OS. 

[0039] At first, what is described is an operation for 
terminating and restarting OS-B while operating contin- 
uously OS-A. In case that OS-B is shut down, or that 
OS-B is made terminated forcibly due to an exception, 
a routine of th inter-OS control software 23 is called 



and is made notified. As the inter-OS control software 
23 does not allow OS-B to be switched from its suspend 
state to being in operation from this notification onward, 
only OS-A continues to be in operation. As OS-B is 
5 made started in responsive to a designated initialization 
routine called by the inter-OS control software 23, its 
restart can be executed in the similar manner to its or- 
dinary start-up. 

[0040] Next, what is described is an operation for ter- 
10 minating and restarting OS-A while operating continu- 
ously OS-B. When OS-A is shut down, the program ex- 
ecuted on OS-A detects the execution of shut-down op- 
eration and notifies it to the inter-OS control software 
23. When an exception occurs in OS-A, the interrupt 
is handler of the inter-OS control software 23 judges the 
exception. In case that OS-A is shut down or an excep- 
tion occurs, as the inter-OS control software 23 does not 
allow OS-B to be switched from its suspend state to be- 
ing in operation, then OS-A continues to be in operation. 
20 However, if OS-A in a suspend state is made restarted 
in the similar manner to an ordinary start-up, common 
hard wares including a bus shared with OS-B are initial- 
ized, which may prevent OS-B from operating continu- 
ously. In order to solve this problem, a restart operation 
25 is performed in the procedure shown in FIG. 7 after ter- 
minating OS-A. When an electric power is applied, OS- 
A initializes the common hard wares (S51). Then, the 
inter-OS control software 23 operating as a device driver 
is provided with a timing for initialization process for the 
30 hard wares managed by OS-A, in which the context is 
stored (S52). In storing the context, the content of the 
register and the content of all the memory area man- 
aged by OS-A are copied on the memory area managed 
by the inter-OS control software 23. Then, the hard 
35 wares managed by OS-A are initialized by the individual 
device drivers of OS-A (S53). After completing this ini- 
tialization process, OS-A goes to an ordinary operation 
state, and in case that OS-A is terminated due to a shut- 
down operation or an exception, the inter-OS control 
40 software 23 shuts down only OS-A in the above de- 
scribed manner (S54). Then, the inter-OS control soft- 
ware 23 restores the context stored at OS-A automati- 
cally or in responsive to the request from the program 
of OS-B (S55). That is, by referring to the context stored 
45 at the initialization process (S52) for the hard wares 
managed by OS-A, the content of the memory at the 
initialization state is recovered and the content of the 
register is recovered., and then, the operation of OS-A 
is restarted. With this procedure, as the execution of OS- 
50 A is restarted immediately after completing the set-up 
of the common hard wares managed by OS-A, and OS- 
A can be operated in an ordinary mode after only initial- 
izing the hard wares managed by OS-A, there is no need 
for initializing again the common hard wares shared by 
55 OS-B. 

[0041] In this embodiment, as for OS-A used as a ver- 
satile OS, only the process for the int rrupt controller 1 9 
is modified, and other process or components ar not 
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modified. This makes it easier to add OS-B and the inter- 
OS control software 23 for OS-A used as a versatile OS. 
[0042] According to the present invention, when op- 
erating plural OS's on a single CPU in the control appa- 
ratus, the area of influence of the abnormal behavior of s 
OS's and their related programs can be localized, and 
the abnormal state can be transferred to an ordinary op- 
eration mode only by restarting the partial component 
on the basis of the individual OS's without terminating 
the whole control apparatus, which leads to increasing 10 
the reliability of the system In addition, the operation of 
OS's can be observed from the space independent of 
the spaces for the ordinary operation of OS's and their 
programs. 



Claims 

1. An multiple operating system control method for a 
multiple operating system having plural operating 20 
systems executed in a digital arithmetic processor 

in which a first operating system and a second op- 
erating system of said plural operating systems are 
alternately switched and executed on said digital 
arithmetic processor, comprising 25 

A process for reserving an interrupt number 
or an input and output address used by said second 
operating system for said first operating system 
when starting said first operating system. 

30 

2. An multiple operating system control method of 
Claim 1, wherein 

a conversion table used for said digital arithme- 
tic processor converting a virtual memory ad- 35 
dress to a physical address is defined said in- 
dividual operating system; and 
when executing a switching procedure for se- 
lecting one of said operating systems, which is 
called as a interrupt processing routine or 40 
called by said first and second operating sys- 
tems individually when an interrupt occurs, a 
procedure for directing said digital arithmetic 
processor to use conversion table for an oper- 
ating system to be executed after switching is 45 
executed when selecting and switching an op- 
erating system. 

3. An multiple operating system control method of 
Claim 1, wherein so 

a priority level is made assigned to an individual 
operating system in operation; and 
by means that an operating system with a lower 
priority level is made not selected and execut- ss 
ed, or is made switched in a definite time inter- 
val and then an operating system with a higher 
priority level is called back again while a pro- 



gram executed on an operating system with a 
higher priority level continues its operation a 
program executed on said operating system 
with a higher priority level is executed in pref- 
erence. 
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FIG. 3 
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FIG. 4 
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FIG. 5 
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FIG. 6 
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